The bearer independent call control (BICC) protocol is a signaling protocol based on narrowband-ISDN user part (N-ISUP) that is used to support narrowband integrated services digital network (ISDN) service over a broadband backbone network. Specified by the International Telecommunications Union-Telecommunications Standardization Sector (ITU-T) in recommendations Q.1901 and Q.1902, BICC supports narrowband ISDN services independently of bearer and signaling message transport technology. The BICC architecture also separates the call control function from the bearer control function.
As specified by the ITU-T, a BICC-capable signaling point (SP) is statically provisioned with a routing table which associates, among other things, a range of call instance code or CIC values with each BICC SP in the mesh. These ranges are mutually agreed upon between the BICC SPs. ISUP uses the same acronym, CIC, for “circuit identification code” which identifies the circuit being used for end user communications. The circuit identifier code and the call instance code are each used by their respective protocol for the identification of a signaling relation between peer entities and the association of signaling messages to that relation. Unlike the circuit identification code in ISUP, the call instance code in BICC is not specified in the BICC standards documents as identifying a physical circuit. However, the call instance code in BICC can also be used to identify a physical circuit or bearer connection without departing from the scope of the subject matter described herein. The acronym, CIC, as used hereinafter, is intended to refer to the call instance code.
Prior to initiating a call, an originating BICC SP must select a destination BICC SP and an associated call instance code that is based, at least in part, on the called party's dialed digits. The originating BICC SP then sends a message to the destination BICC SP using the call instance code.
The ITU-T specifications also provide an element called a call mediation node (CMN). As specified, a CNM hosts a coordinating call service function (CSF-C) but lacks a bearer control function (BCF). A CSF-C communicates with all other types of CSFs (e.g., coordinating, gateway, nodal, transit). According to ITU-T Q.1202.4, when the CMN receives a signaling message, the CMN selects a free call instance code and sends the message to the next CSF. Q.1202.4 does not specify how the originating node selects the original call instance code to be included in the IAM message or steps to be performed by the CMN that are part of the same signaling session.
One problem not addressed in the BICC specifications is how a CMN interacts with the BICC-capable SPs within a mesh topology. As mentioned, the BICC SPs must bilaterally agree on the call instance code ranges used between them. If a CMN is present then this creates an additional barrier to communication. For example, if a BICC SP 1 sends a call setup message, it must first select an available call instance code associated with the destination BICC SP. If a CMN is in the middle of the mesh, BICC SP 1 does not know in advance which SP will receive the message, since when the CMN receives a message it performs a routing function that is unknown to the message originator. Therefore, BICC SP 1 cannot choose an appropriate call instance code to use. Furthermore, with full-mesh topology, each time a new BICC SP is added to the mesh, the routing tables of all BICC SPs and CMNs in the network must be updated or re-provisioned.
Another problem not addressed is congestion and unbalanced loads among BICC SPs. Since an originating BICC SP is unaware of the loading status of the selected destination or next-hop BICC SP, the originating BICC SP may be sending messages to a congested BICC SP when a less congested BICC SP is available, thereby exacerbating the congestion and decreasing throughput and efficiency of the network.
Thus, there exists a long felt need for methods, systems, and computer readable media for centralized routing and call instance code management that avoids at least some of the difficulties not addressed by the BICC specifications.